Columbia Kermit/kermit.zip/newsgroups/misc.20020314-20021006/[e-mail]_Thu Apr 25 14:47:26 EDT 2002.msg

Text File | 2020-01-01 | 7KB | 175 lines

Article: 13336 of comp.protocols.kermit.misc
Path: newsmaster.cc.columbia.edu!panix!newsfeed.mathworks.com!news.maxwell.syr.edu!newsfeed.media.kyoto-u.ac.jp!newsfeed.rim.or.jp!news.rim.or.jp!not-for-mail
From: Ishikawa <[e-mail]>
Newsgroups: comp.protocols.kermit.misc
Subject: Re: a bug on GNU/linux: speed reset to unintended value occasionally.
Date: Fri, 26 Apr 2002 03:36:22 +0900
Organization: Ye 'Ol Disorganized NNTPCache groupie
Lines: 151
Message-ID: <[e-mail]>
References: <[e-mail]> <a8svsu$3vl$[e-mail]> <[e-mail]> <[e-mail]> <aa6sjh$1a9$[e-mail]>
NNTP-Posting-Host: pl133.nas911.n-yokohama.nttpc.ne.jp
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
X-Trace: news.rim.or.jp 1019759787 5002 210.139.98.133 (25 Apr 2002 18:36:27 GMT)
X-Complaints-To: [e-mail]
NNTP-Posting-Date: Thu, 25 Apr 2002 18:36:27 +0000 (UTC)
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686)
X-Accept-Language: ja, en
Cache-Post-Path: duron!unknown@localhost
X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/)
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13336

Hi,

>
> Control-character "unprefixing" is a relatively new
> development (12 years ago?) that is somewhat risky but,
> like everything else in Kermit, you can control it in
> great detail: down to each individual C0 and C1 control
> character ("help set control" for details).
>
> You can also tell Kermit, when sending a file, to double
> selected characters, which is necessary when passing
> through certain non-transparent devices such as terminal
> servers.  And when receiving files, Kermit can be told
> to discard selected characters that might have been added
> by "something" that sits between the two Kermit programs
> (for example, something that adds a linefeed every time
> it sees a carriage return).
>
    ...
> If you have a truly transparent 8-bit path, then you can
> use "set parity none" (which is the default anyway, or
> "set parity hardware" if you need it) and "set prefixing
> minimal" or "set prefixing none" and get very close to
> the maximum physical speed of the port; sometimes faster,
> because Kermit also does some compression.
>

I tried your suggestion, and found
"set prefixing none" somehow produces slightly lower
throughput than "set control unprefixed all".
Hmm. Could be an artifact or something.

The real kicker is the use of "/transparent"
as in
    send /binary /transparent ./wermit ./wermit.tmp

Using the 8N1 connection at 38400 bps, I got
about 3800 bps. This is close to the bare line speed.
Isn't this great?

I have been unaware of "/transparent" for a long time, but
then I was interested in using KERMIT as terminal emulator
and a `reliable' file transfer engine.

> : Thank you again for the great software package.
> :
> Our pleasure :-)
>
> Since you like Kermit and you are in Japan, maybe now you
> can play with Kermit's character-set conversion.  Did you
> know that when transferring a file in text mode (like
> email, netnews, source code, etc), Kermit can translate
> between any pair of EUC-JP (JIS X 0208), ISO-2022-JP,
> Shift-JIS, JIS-7, DEC Kanji, and Unicode?  For example,
> to send a Japanese text file from a PC that uses
> Shift-JIS to a Linux system that uses EUC-JP...  On the PC:
>

You tempt me :-)

But having done some coding for Japanese character processing,
I tend to shy away from the complex code conversion thingy,
especially since the underlying code standards may change
>from  now and then. You are probably aware of the tome by Ken Lunde:

CJKV Information Processing
 - Chinese, Japanese, Korean & Vietnamese Computing.

The author needs to update online FAQ/errata sheet sometimes
due to the changes in the standard or errata in the
published starndards!

So I usually rely on the latest character conversion
utilities available on each platform which I use at the momement.
(Sun has one. Usually Linux distribution comes  with one.
For that matter, I think Ken Lunde publishes one such program.)

When all else fails, I read the file
using web browsers since these browsers
often contain automatic code conversion for different
Japanese character coding standards. They take care of
the end of line idiosyncrasies rather well.
The last trick works rather well indeed.
(Unless, of course, I need to convert a largish MB
files into a different Japanese character code system.
Often, we can't control the character code system used for
saving a file from browser!)
Oh, I forgot about Macs, too, but since I don't use
Mac often that doesn't count
in my mind at this moment :-)

>   set file character-set shift-jis
>   set transfer character-set utf8
>   send <filename>
>
> On the Linux system:
>
>   set file character-set euc-jp
>   receive
>

Thank you for the tips, I will try
this later on when I am in need of such feature, but
are you sure that
the second topmost command is
 to specify "utf8"?
Is this like specifying the intermediate presentation?
That is, the

    shift-JIS -> utf8 -> euc-jp

I am very unfamiliar with this character code processing
thing in KERMIT. I read the help messages and it seems that
we do need to specify the intermediate character code used
inside the packet using "set transfer character-set utf8".

In any case, the inclusion of these capability into
KERMIT must have been deemed necessary upon popular demands,
and I hope you had a nice feedback from the users of KERMIT.

I have a nagging feeling, though, that KERMIT is
now suffering from "Everything except for the kitchen sink"
syndrome. Emacs is often cited for this
creeping featurism.
This is not a harsh criticism, but
coming from a Kermit user for quite a long while,
it is a comment to express the wonder of
seeing a simple communication program being
transformed into a powerful program with so many features
over two decades.

I suspect that KERMIT DOES need to grow up along
with its surroundings. We no longer use ONLY serial line
for communication as in the early 1980's.

For that matter, the inclusion of ssh/scp
functions, I heartily welcome and think
of it appropriate for Internet usage!

So again please keep up the good work going!

Happy Hacking.

PS:  I have a feeling that KERMIT will live on until
Frank retires from Columbia university
and/or the last KERMIT devotee
will die on the earth.
(But then someone comes along and find a copy of
KERMIT being used for monitoring remote router/remote
scientific station, etc. and then that someone
might become hooked and become a KERMIT user again...)